[% setvar title The Perl 6 Summary for the week ending 20031214 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20031214'></a><h1>The Perl 6 Summary for the week ending 20031214</h1>
<p>It looks like things are starting to slow down slightly as we run up
to Christmas, but the quality of discussion remains high. We'll start
with the usual trawl through perl6-internals.</p>
<a name='Testing for null'></a><h2>Testing for null</h2>
<p>Dan ruled on last week's discussion of testing for undef in
Parrot. We're getting a new <code>isnull</code> branch op along with a new Undef
PMC. Leo T&ouml;tsch implemented it with his usual alacrity.</p>
<p><a href='http://groups.google.com/groups?selm=a06010209bbfa414ccf86@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='How many comparison ops do we need again?'></a><h2>How many comparison ops do we need again?</h2>
<p>One of the annoyances of writing something that's really going to be
used is that you can't get away with the equivalent of outlining your
proof on the blackboard, waving your hands and saying &quot;The details are
left as an exercise for the interested reader&quot;. A case in point is
Parrot's array of comparison branch operators. For a while now we've
been getting by with a sparsely populated array of such beasties. This
week saw people (well, okay then, Leo, but he has the productivity of
people) doing the detail work to get the full range implemented.</p>
<p><a href='http://groups.google.com/groups?selm=a06010208bbfa40078332@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Incorrect scoping of constants in IMCC'></a><h2>Incorrect scoping of constants in IMCC</h2>
<p>Dan wasn't happy with the scoping of the <code>.const</code> directive in IMCC
(essentially constants are sub/block scoped, which makes them pretty
much useless for the things constants are normally used for). Melvin
Smith made the fix.</p>
<p><a href='http://groups.google.com/groups?selm=a06010227bbfbec732329@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Objects and Namespaces'></a><h2>Objects and Namespaces</h2>
<p>Dan had mandated that the Parrot internal equivalent of the Perlish
<code>Package::Name</code> should be <code>Package\0Name</code>. Nobody (Dan included)
liked the embedded nulls mandated in Dan's original spec. After some
discussion he posted a description of a new hierarchical namespace
design.</p>
<p>Dan pointed out that the use of hierarchical namespaces would probably
mean that the semantics (and syntax) of <code>find_global</code> would need to
be adjusted.</p>
<p><a href='http://groups.google.com/groups?selm=a06010229bbfc0dac4e0a@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<p><a href='http://groups.google.com/groups?selm=a0601020bbbfe5002d599@' target='_blank'>groups.google.com</a>[10.0.1.2] -- The New Namespace</p>
<a name='Dan Sugalski, IMCC Bugfinder General'></a><h2>Dan Sugalski, IMCC Bugfinder General</h2>
<p>Dan's been writing more PIR code by hand, and is discovering
infelicities as he goes.</p>
<p><a href='http://groups.google.com/groups?selm=a06010207bbfd4f47dab9@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<p><a href='http://groups.google.com/groups?selm=a06010208bbfd52feb9be@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Macros, PIR and PASM'></a><h2>Macros, PIR and PASM</h2>
<p>Following his bout of IMCC bug spotting, Dan announced a decision about
macros in PIR and PASM code. Essentially, Parrot's built in PIR and
PASM parsers do not need to do macros as 'macro assemblers are for
people, not compilers'. Because of this, Dan would like to see any
macro processing moved out of the core binary and into an external
tool. (Which can always be invoked via the hypothetical
<b><i>macro-parrot.pl</i></b>). Melvin Smith suggested that it would probably be
worth extracting the existing macro processor from imcc.l and moving
it into a separate library.</p>
<p><a href='http://groups.google.com/groups?selm=Pine.LNX.4.58.0312121357440.2785@okcomputer.antiflux.org' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<p>The language list continues to fascinate (and not in the 'car crash'
way it has done on occasions in the past) with an ongoing conversation
between Larry on the one hand (seemingly designing on the hoof and
certainly doing a great deal of thinking aloud) and everyone else on
the other hand getting clarification or extrapolating to the point
where Larry has to step in and do a little bit more design.</p>
<p>I'm finding it hard to do a proper summary of what's going on because
so much is changing (and because so much of what seems to be set in
quick drying concrete now is so novel.)</p>
<p>Essentially the discussion revolves around Roles, which are sort of
like Java interfaces, sort of like mixins and nothing like either. In
his 'Vocabulary' post, Luke Palmer describes a Role as 'A collection
of methods [and/or attributes] to be incorporated into a class sans
inheritance [...]. Used with <code>does</code>'.  In this new world, a property
(<code>$bar but Red</code> etc) is a kind of degenerate role.</p>
<p>At the same time though, we're getting other gems. For instance, Perl
6 is going to get something a little like <code>final</code>, but instead of it
being a declaration made in a type's implementation (&quot;This is the one,
the only Integer and you may not inherit from it or ever alter it!&quot;),
it will become a promise made by a type's user not to attempt to
monkey with it come run time, which should set the code generator free
to use optimizations that aren't safe when everything's dynamic.</p>
<p>So, if you're interested in how Perl 6's OO system is going to work,
now is the time to get involved in the language list. If there's
something you've always wanted to do or something about Perl's current
OO that you love and want to retain, it's time to speak up for it. The
odds are good that you'll be able to do what you want using the
mechanisms being designed, but you'll be kicking yourself later if it
turns out you can't.</p>
<p>If you do join in, you'll see references to the 'Traits Paper'. This
is where the original idea for what Larry's calling 'Roles' came
from. When you read it, bear in mind that the authors of the paper
use the term 'trait' for what we're calling a 'role' (We already have
traits you see).</p>
<p><a href='http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf' target='_blank'>www.cse.ogi.edu</a> -- Traits paper</p>
<a name='Iterating through two arrays at once'></a><h2>Iterating through two arrays at once</h2>
<p>Joe Gottman asked for some clarification about which was more right,
Apocalypse 4 (<code>for @a ; @b -&gt; $a ; $b {...}</code>) or <i>Perl 6
Essentials</i> (<code>for zip @a, @b -&gt; $a, $b {...}</code>) when talking about
Essentials&gt; iterating through two (or more) arrays
at once. The rule of thumb for this seems to be 'latest publication
date wins' so <i>P6E</i> is the most correct. He went on to wonder what
happens when one array is shorter than the other (an undefined value
is passed into the loop when the array runs out of values until the
last array is exhausted). He wondered what would happen if any of the
arrays contained <code>undef</code>; how would the body of the loop be able to
differentiate between a 'valid' undef and one created by the loop
itself.</p>
<p>Larry pointed out that, in Perl 6, undef isn't necessarily unique and
may well contain an unthrown exception with extra information hidden
in a property.</p>
<p><a href='http://groups.google.com/groups?selm=011701c3bfa1$6e97fc40$42404a18@carolina.rr.com' target='_blank'>groups.google.com</a></p>
<a name='Vocabulary'></a><h2>Vocabulary</h2>
<p>If you're even vaguely interested in the workings of Perl 6's object
system, you need to read the referenced post.</p>
<p>Luke Palmer, worrying about people using Object related vocabulary in
subtly inconsistent ways, posted a glossary explaining how OO
terminology is used in a Perl 6 context. Casey West wrapped it up in a
POD, which will, I hope, end up on dev.perl.org soon.</p>
<p>Of course, there were a few corrections for subtleties, a few rethinks
of the design so far, and general gratitude for at least having a
baseline document that people could refer to.</p>
<p><a href='http://groups.google.com/groups?selm=20031212112302.GA27893@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=20031212175822.GA80586@geeknest.com' target='_blank'>groups.google.com</a> -- Casey's POD</p>
<a name='Enums and bitenums'></a><h2>Enums and bitenums</h2>
<p>St&eacute;phane Payrard wondered if Perl 6 would have enums and
bitenums directly supported in the language (he pointed out that it
wouldn't be hard to implement them using macros of course). Larry
speculated that enums might just end up being special cases of
roles/subtypes.</p>
<p>Further down the thread, Uri Guttman commented that Larry seemed to be
working on a grand unification and wondered if string theory had any
place in it. (Actually, it's been apparent for ages now that a great
deal of the power that Larry's putting into Perl 6 arises from the
unifications he's making, but that's an article for my weblog I
think).</p>
<p><a href='http://groups.google.com/groups?selm=20031211134806.GA3771@stefp.dyndns.org' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, Apologies, Announcements'></a><h1>Acknowledgements, Apologies, Announcements</h1>
<p>For the duration of the panto season, Leon Brocard will be appearing
in the role of Pumpking in a Perl 5 Porters summary near you.</p>
<p>Still no link shortening. I appear to have managed to subtly screw my
Perl installation and now I can't get the link shortening module
installed. I shall try and make time to fix it this week.</p>
<p>Unless someone beats me to it (please someone, beat me to it) I'm
going to try and put together a 'state of play' post, summarizing the
current state of the Perl 6 Object system with a little more
background in it than Luke Palmer's excellent 'Vocabulary' post. All
being well it'll be appearing in next week's summary.</p>
<p>If you find these summaries useful or enjoyable, you might like to
contribute to the Perl Foundation to help support the ongoing
development of Perl. I also welcome feedback at
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i> or at my website.</p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://www.bofh.org.uk:8080/' target='_blank'>www.bofh.org.uk</a> -- My website, Just a Summary</p>
</div>
